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Verfahren zu Uberp riifung der Sicherheit und Zuveriassiakeit 
sof twar ebasierter elektronischer Systeme 



15 Die Erfindung betrifft ein Verfahren zur Oberpriifung der 
Sicherheit und ZuverlSssigkeit sof twarebasierter 
elektronischer Systeme unter Verwendung einer 
Zuveriassigkeitsfunktion zur tjberprtifung der geforderten 
Funktionen des Systems auf der Grundlage der hierfur 
notwendigen Hardware-Komponenten des Systems. Weiterhin 
betrifft die Erfindung Verwendungen dieses Verfahrens sowie 
ein Computerprogramm und Computerprogrammprodukt zur 
Implementierung des Verfahrens. 



25 Stand der Technik 



Zuveriassigkeits- und Sicherheitsanforderungen bspw. an 
Fahrzeugfunktionen ergeben sich aus den Kundenwunschen 
unter Berucksichtigung der technischen, gesetzlichen und 
finanziellen Randbedingungen. ZuverlSssigkeitsanf orderungen 
an Fahrzeugfunktionen werden beispielsweise in Form von 
kurzen Reparaturzeiten oder langen Serviceintervallen 
vorgegeben. Sicherheitsanforderungen legen dagegen das 
sichere Verhalten des Fahrzeugs im Falle von Ausfailen und 
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StSrungen von Komponenten des Fahrzeugs fest. Die an 
Fahrzeugfunktionen gestellten Zuveriassigkeits- und 
Sicherheitsanforderungen legen von Anfang an auch 
Anforderungen an die technische Realisierung und 
Nachweispflichten fest. Eine der mSchtigsten Mafinahmen zur 
Erhahung der Sicherheit und Zuveriassigkeit ist Redundanz. 
Da zunehmend Fahrzeugfunktionen oder Teile von 
Fahrzeugfunktionen durch Software realisiert werden, haben 
systematische Methoden zur Zuveriassigkeits- und 
Sicherheitsanalyse auch zunehmenden Einfluss auf die 
Software-Entwicklung ftir elektronische SteuergerSte, etwa 
auf die Realisierung der Oberwachungs-, Diagnose- und 
Sicherheitskonzepte . 

Far komplexe elektronische Systeme miissen die Aktivitaten 
zur Absicherung der Zuveriassigkeit und Sicherheit 
frahzeitig geplant und in den gesamten Projektplan 
integriert werden. 



Unter deiti Begriff „System« soil im Rahmen vorliegender 
Anmeldung je nach Kontext das Folgende verstanden werden: 
Der zum Erreichen einer bestimmten Funktion notwendige 
kleinste Systemabschnitt, zusammenwirkende Systemabschnitte 
bis hin zum Gesamtsystem oder - noch weiter gefasst - das 
Gesamtsystem unter Einschluss der Bedienpersonen oder 
anderer auf das Gesamtsystem wirkender Elemente. Zur 
Eriauterung der Erfindung wird im Rahmen vorliegender 
Anmeldung im Wesentlichen auf Systeme Bezug genommen, die 
Bestandteil von Fahrzeugsteuerungen sind. Diese Bezugnahme 
hat rein eriauternden Charakter und soil die Erfindung in 
keiner Weise auf solche Systeme beschranken. Die Erfindung 
besitzt vielmehr generell in Bezug auf sof twarebasierte 
elektronische Systeme Gultigkeit. 
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Zur Oberprafung der Sicherheit und Zuverlassigkeit solcher 
Systeme ist die Verwendung von Zuverl^ssigkeitsfunktionen 
bekannt, mit Hilfe derer der Grad der Zuverlassigkeit far 
geforderte Funktionen des Systems angegeben werden kann 
Zum Bestimmen einer solchen ZuverlSssigkeitsfunktion kann 
von den Zuveriassigkeiten der fur die geforderten 
Systemfunktionen notwendigen Hardware komponenten des 
systems ausgegangen werden. ZuverlSssigkeitsanalysen 
umfassen z.B. Ausfallraten- und Ausf allartenanalysen, wie 
die Ausfallarten- und Wirkungsanalyse (FMIA) oder die 
Fehlerbaumanalyse (FTA) . im Folgenden soli eine 
Zuveriassigkeitsanalyse anhand einer Ausf allratenanalyse 
unter Berechnung der ZuverlSssigkeitsf unktion anhand eines 
Zuveriassigkeitsblockdiagramms ftir ein betrachtetes System 
naher eriautert werden. 

Die systematische Untersuchung der Ausfallrate einer 
Betrachtungseinheit ermSglicht die Voraussage der 
Zuverlassigkeit ftir die Betrachtungseinheit durch 
Berechnung. Diese Voraussage ist wichtig, urn Schwachstellen 
frtihzeitig zu erkennen, Alternativl5sungen zu bewerten und 
Zusammenhange zwischen Zuverlassigkeit, Sicherheit und 
Verftigbarkeit quantitativ erfassen zu k5nnen. Aufierdem sind 
Untersuchungen dieser Art notwendig, um 

Zuveriassigkeitsanforderungen etwa an Systemkomponenten 
stellen zu kOnnen. 

infolge von Vernachiassigungen und Vereinf achungen, sowie 
der Unsicherheit der verwendeten Eingangsdaten kann die 
berechnete, vorausgesagte Zuverlassigkeit nur ein 
Schatzwert ftir die wahre Zuverlassigkeit sein, die nur mit 
ZuverlassigkeitsprUfungen und Feldbeobachtungen zu 
ermittem ist. Im Rahmen von Vergleichsuntersuchungen in 
der Analysephase spielt jedoch die absolute Genauigkeit 
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keine Rolle, so dass besonders bei der Bewertung von 
Realisierungsalternativen die Berechnung der vorausgesagten 
Zuveriassigkeit ntitzlich ist. 

In den folgenden Abschnitten ist die Betrachtungseinheit 
immer ein technisches System oder eine Systemkomponente des 
Fahrzeugs. Im allgemeinen Fall kann die Betrachtungseinheit 
auch weiter gefasst werden und beispielsweise auch den 
Fahrer des Fahrzeugs mit einschlieJien. 

Die Ausfallratenanalyse (siehe hierzu Alessandro Birolini: 
Zuveriassigkeit von GerSten und Systemen. Springer Verlag, 
1997) unterscheidet die folgenden Schritte: 

o Definition der Grenzen und Komponenten des technischen 
Systems, der geforderten Funktionen und des 
Anforderungsprofils 

o Aufstellen des Zuverlassigkeitsblockdiagramms (engl. 
Reliability Block Diagram) 

Bestimmung der Belastungsbedingungen far jede 
Komponente 

o Bestimmung von Zuverlassigkeitsfunktion oder 
Ausfallrate fUr jede Komponente 

Berechnung der Zuverlassigkeitsfunktion far das System 
Behebung der Schwachstellen 



o 
o 



Die Ausfallratenanalyse ist ein mehrstufiges Verfahren und 
kann „top down- von der Systemebene aber die verschiedenen 
Subsystemebenen bis zur Komponentenebene der technischen 
Systemarchitektur durchgefQhrt werden. Die 
Ausfallratenanalyse muss nach Anderungen der technischen 
Systemarchitektur wiederholt werden. 
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Im Folgenden soil der erste Schritt der Ausf allratenanalyse 
naher erlSutert werden. 

Ftir die theoretischen Oberlegungen, die zur Voraussage der 
Zuveriassigkeit notwendig sind, sollten eingehende 
Kenntnisse des Systems und seiner Funktionen, sowie der 
konkreten MOglichkeiten zur Verbesserung der 
Zuveriassigkeit und Sicherheit vorausgesetzt werden. 
Zum Systemverstandnis zahlt die Kenntnis der Architektur 
des Systems und seiner Wirkungsweise, die Arbeits- und 
Belastungsbedingungen far alle Systemkomponenten, sowie die 
gegenseitigen Wechselwirkungen zwischen den Komponenten, 
etwa in Form von Signalf Itissen und der Eingangs- und 
Ausgangssicht aller Komponenten. 

Zu den VerbesserungsmSglichkeiten gehSren die Begrenzung 
Oder die Verringerung der Belastung der Komponenten im 
Betrieb, etwa der statischen oder dynamischen Belastungen, 
der Belastung der Schnittstellen, der Einsatz besser 
geeigneter Komponenten, die Vereinf achung des System- oder 
Komponentenentwurfs, die Vorbehandlung kritischer 
Komponenten, sowie der Einsatz von Redundanz. 

Die geforderte Funktion spezifiziert die Aufgabe des 
Systems. Die Festlegung der Systemgrenzen und der 
geforderten Funktionen bildet den Ausgangspunkt jeder 
Zuveriassigkeitsanalyse, weil damit auch der Ausfall 
definiert wird. 

Zusatzlich mtissen die Umweltbedingungen fur alle 
Komponenten des Systems definiert werden, da dadurch die 
Zuveriassigkeit der Komponenten beeinflusst wird. So hat z. 
B. der Temperaturbereich grolJen Einfluss auf die 
Ausfallrate von Hardware-Komponenten . im Fahrzeug gehSren 
2. B. der geforderte Temperaturbereich, der Einsatz unter 
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Feuchtigkeit, Staub oder korroslver Atmosphere, oder 
Belastungen durch Vibrationen, Schocks oder Schwankungen, 
wie etwa der Versorgungsspannung zu den Umweltbedingungen 
Hangen die geforderten Funktionen und die Umweltbedingungen 
aufierdem von der Zeit ab, muss ein Anf orderungsprof il 
festgelegt werden. Ein Beispiel ftlr gesetzlich 
vorgeschriebene Anf orderungsprof ile im Fahrzeug sind die 
Fahrzyklen zum .Nachweis der Einhaltung der 
Abgasvorschriften. In diesem Fall spricht man auch von 
reprasentativen Anf orderungsprof ilen . 

Nachstehend wird der zweite Schritt der Ausfallratenanalyse 
naher erlSutert. 

Das Zuverlassigkeitsblockdiagramm gibt Antwort auf die 
Fragen, welche Hardware-Komponenten • eines Systems zur 
Erfullung der geforderten Funktion grundsatzlich 
funktionieren massen und welche Hardware-Komponenten im 
Falle ihres Ausfalls die Funktion nicht grundsatzlich 
beemtrachtigen, da sie redundant vorhanden sind. Die 
Aufstellung des ZuverlSssigkeitsblockdiagramms erfolgt 
xndem man die Komponenten der technischen Systemarchitektur 
betrachtet. Diese Komponenten werden in einem Blockdiagramm 
so verbunden, dass die zur Funktionserf Ollung notwendigen 
Komponenten in Reihe geschaltet werden und redundante 
Komponenten in einer Parallelschaltung verbunden werden. 

Figur 1 stent schematisch ein so genanntes Brake-By-Wire- 
System 1 dar, wobei das Bremspedal 2, das SteuergerSt 3 
sowie die vier Bremseinheiten, nSmlich die Bremseinheit 4 
vorne links, die Bremseinheit 5 hinten links, die 
Bremseinheit 6 vorne rechts sowie die Bremseinheit 7 hinten 
rechts, dargestellt sind. Die far eine Funktion des Systems 
1 notwendigen Hardware-Komponenten sind mit K bezeichnet 
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Ftir ein fiktives Brake-By-Wire-System 1, wie in Figur 1 
dargestellt, wird zunachst die Systemgrenze festgelegt. Das 
System besteht aus den Komponenten Bremspedaleinheit (Ki ) , 
5 Steuergerat (K2) , den Radbremseinheiten (K5, , K7, Kg ,Kii) 
und den elektrischen Verbindungen (K3,, K4, Kg, Kg, Kio) . 

Bei Brake-By-Wire-Systemen besteht zwischen dem Bremspedal 
und den Radbremsen keine hydraulische, sondern eine 

10 elektrische Verbindung. Beim Bremsen wird der Fahrerbef ehl, 
der durch die Bremspedaleinheit Ki vorgegeben und im 
Steuergerat K2 verarbeitet wird, und die zxim Bremsen 
notwendige Energie „by wire" zu den Radbremseinheiten K5, 
K7, Kg und Kii tibertragen. Dabei muss sichergestellt werden, 

15 dass die Obernahme der Funktionen „Inf ormations- und 
Energietibertragung" zwischen Pedaleinheit und 
Radbremseinheiten, die bei konventionellen Bremssystemen 
mechanisch-hydraulisch realisiert sind, durch die 
elektrischen und elektronischen Komponenten K2, K3, K4, Kg, 

20 Ks und Kio kein zusStzliches Sicherheitsrisiko, sondern 
einen Sicherheitsgewinn bringt. Die vorhersagbare 
Obertragung der Bremsbefehle ist deshalb eine zwingende 
Voraussetzung. Ebenso muss die Sicherheit auch bei 
Storungen und Ausf alien von Komponenten gewahrleistet sein. 

25 

Es soil die Funktion ^Bremsen"" betrachtet werden. Daftir 
soli die Gesamtzuveriassigkeit des Systems bestimmt werden. 
Es wird angenoramen, dass die Ausf allraten Xi bis An der 
Komponenten Ki bis Kn bekannt sind. 

30 

Dieses Beispiel wird im weiteren sehr stark vereinfacht. Es 
soil nur die prinzipielle Vorgehensweise bei der 
Zuveriassigkeitsanalyse verdeutlichen. Deshalb wird nur die 
Informationsubertragung betrachtet, wahrend die Aspekte der 
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Energieversorgung und der Energieabertragung, sowie 
fahrdynamische Randbedingungen, wie die geforderte 
Bremskraftverteilung auf Vorder- und Hinterachse, die 
selbstverstandlich auch bei der Zuverlassigkeitsanalyse 
berticksichtigt werden mtissen, vernachlassigt werden. 

Ftir die Erfailung der Funktion „Brenisen" sind bei dieser 
vereinfachten Sicht das Funktionieren der Komponenten 
Bremspedaleinheit Ki, Steuergerat Kz, sowie der 
Verbindungen zwischen Bremspedaleinheit und Steuergerat K3 
zwingend notwendig. 

Bei den Radbremseinheiten und den Verbindungen zwischen 
Steuergerat und Radbremseinheiten ist Redundanz vorhanden. 
Unter der stark vereinfachten Annal^e, dass eine 
ausreichende Hilf sbremswirkung far das Fahrzeug mit nur 
einer Radbremseinheit erzielt werden kann, sind dann 
beispielsweise die Komponenten K, und K5 notwendig, wahrend 
die Komponenten Kg und K7, Kg und Kg bzw, Kio und Kn 
redundant vorhanden sind. Eine derartige Anordnung wird 
auch als l-aus-4-Redundanz bezeichnet. 

Das Zuverlassigkeitsblockdiagramm ftir die Funktion 
„Bremsen^^ sieht dann wie in Figur 2 dargestellt aus. 

Nach Festlegung der Belastungsbedingungen und der 
Bestimmung der Zuveriassigkeitsfunktionen Ri{t) ftir alle 
Komponenten Ki, kann unter Berticksichtigung der in 
nachstehender Tabelle 3 dargestellten Grundregeln fUr 
Zuveriassigkeitsblockdiagramme die Zuveriassigkeitsfunktion 
des Systems Rs(t) berechnet werden. 
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Tabelle 3: Einige Grundregeln zur Berechnung der 

Zuverlassigkeitsfunktion ftir das Syst« 



:em 



Zuverl&sig^eits- 
blodcdiagratmn 


Zuvo-lSssigkeits- 
funktion 

Rs=Rs(tXRi=Ri(t) 


Aus&llrate 

filr \ = konsfaint: 

Ri(t) = e-»«» 


Beispiel 












i«l 


i=l 


R,=R2=0,9 

Rs = 0,9 -0,9 =0,81 


l-aus 


> - 
!-2-Red 


} 

undanz 


Rs = l-(l-R,Xl-R2) 




R,=R2=0.9 

Rs= 1-0-0,9X1-0,9) =0,99 


ri 
-1 

-i 

k-au 


> K < 
s-n-Red 


-> 

> 
>• 

undanz 


Fiirk=lgUt: 
Rs=l-(1-R)- 




R,=R2=R3=R4=0,9 
bei l-aus-4-Redundffiiz: 

Rs=l- (1-0,9)* =0,9999 



10 



15 



Ftir das Beispiel in Figur 2 kann damit die 
Zuverlassigkeitsfunktion des Systems Rs berechnet werden 
Mit den Annahmen R, = R, = R3 = r,, ^^d R5 = R, = R, = r,, 
folgt ftir Rs: 

Rs = Ri R2 R3 [1- (I-R4 R5)4] 

Wie dieses vereinfachte Beispiel zeigt, erhOht sich die 
Systemzuveriassigkeit ftir eine Funktion durch redundante 
Komponenten im Zuveriassigkeitsblockdiagramm gegentiber der 
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Komponentenzuveriassigkeit. Dagegen verringert sich bei den 
seriell dargestellten Komponenten die Systemzuveriassigkeit 
gegeniiber der Komponentenzuveriassigkeit . Man wird daher 
ftlr die seriellen Komponenten im 
5 Zuveriassigkeitsblockdiagramm bereits eine hohe 

Zuveriassigkeit von den Komponenten fordern mtlssen oder 
eine technische Systemarchitektur einftihren, die auch hier 
redundante Strukturen vorsieht. 



15 



10 Wahrend oben die Berechnung der ZuverlSssigkeitsfunktion 

fiir ein System ftir eine bestimmte geforderte Systemfunktion 
exemplarisch und stark vereinfacht dargelegt worden ist, 
ist es in Shnlicher Weise erstrebenswert/ Aussagen Uber die 
Sicherheit eines Systems treffen zu kOnnen. Filr die 
Sicherheit eines Systems ist es haufig irrelevant, ob die 
Betrachtungseinheit die geforderten Funktionen erfailt oder 
nicht, sofern damit kein nicht vertretbar hohes Risiko 
eintritt. Softwarebasierte elektronische Systeme, wie sie 
in vorliegender Anmeldung betrachtet werden, bestehen 
hauptsachlich aus Hardware-Komponenten sowie Software- 
Komponenten, wobei die Sof tware-Komponenten meist auf 
einige der Hardwarekomponenten des Systems verteilt sein 
kOnnen. Es besteht ein starkes Bedtirfnis, sowohl die 
Sicherheit als auch die Zuveriassigkeit solcher 
25 softwarebasierter elektronischer System verlasslich 
aberprtifen zu kOnnen. 



20 



Beschreibung der Erfindung und Vorteile 

Erfindungsgemafi wird eine ZuverlSssigkeitsf unktion 
Berechnung der Zuveriassigkeit mindestens einer der 
geforderten Funktionen des Systems und eine weitere 
Zuveriassigkeitsfunktion zur Berechnung der 
Zuveriassigkeit mindestens einer der 
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Sicherheitsfunktionen des Systems bestimmt, wobei bei 
der Bestimmung dieser Zuveriassigkeitsfunktionen auch 
Software-Komponenten des Systems mit berticksichtigt 
werden. Die Software-Komponenten werden dabei anhand 
der Hardware-Komponenten, auf die diese 
Softwarekomponenten verteilt sind, mit berticksichtigt 
Dxese Berticksichtigung kann sich dabei auf die 
Hardware-Komponente (n) selbst sowie auch auf die 
entsprechenden Hardware-Verbindungen erstrecken, die 
von der jeweiligen Software-Komponente (z.b. durch 
Abgabe eines Ausgangssignals) beeinflusst werden 
Hierdurch ist es erstmals mSglich, Aussagen aber die 
Sicherheit und Zuveriassigkeit eines softwarebasierten 
elektronischen Systems zu treffen, wobei diese Aussagen 
das aus Hardware- und Software-Komponenten 
einschliefilich der jeweiligen Verbindungen bestehende 
System betreffen und sich nicht nur auf die Hardware- 
Komponenten beschrSnken. 

Sicherheit und ZuverlSssigkeit des Hardware- und 
Software-Komponenten umfassenden Systems werden unter 
Verwerldung einer Zuverlassigkeitsfunktion tiberpruft 
die bspw. anhand des eingangs erlauterten 
Zuveriassigkeitsblockdiagramms ftir das System bestimmt 
werden kann. Wie nachstehend erlautert wird, werden 
erfindungsgemafi die Software-Komponenten des Systems 
bei der Bestimmung der Zuverlassigkeitsfunktion mit 
berticksichtigt. Dies ko^nt einer neuen Systemdef inition 
glexch, da bisher fUr Zuverlassigkeitsanalysen nur ein ' 
aus Hardware-Komponenten bestehendes System betrachtet 
wurde und die Software-Komponenten - wenn tlberhaupt - 
emer eigenen gesonderten Analyse unterzogen wurden 
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Mit der Erfindung ist die frtlhzeitige Bewertung 
unterschiedlicher Oberwachungskonzepte elektronischer 
Steuergerate im Besonderen und von Funktionen 
elektronischer Systeme im Allgemeinen, die durch 
software und Hardware realisiert werden, hinsichtlich 
der erreichbaren Systemsicherheit und der 
Systemzuveriassigkeit mSglich. Die Ergebnisse 
beeinflussen insbesondere die Verteilung von Software- 
Funktionen auf die Mikrocontroller vernetzter 
Steuergerate und damit die Entwicklung von Software ftir 
verteilte und vernetzte Steuergerate. 



zu 



Urn Aussagen tiber das System im Gesamten tref fen 
kennen, ist es sinnvoll, alle Funktionen des Systems, 
also alle geforderten Systemfunktionen als auch alle 
Sicherheitsfunktionen des Systems mittels Bestimmung 
entsprechender ZuverlSssigkeitsfunktionen zu 
aberprdf eh . 

Zuveriassigkeitsfunktionen nehmen in der Kegel einen 
bestimmten Wertebereich, bspw. von 0 bis 1, ein, wobei 
im Folgenden ohne Beschrankung der Allgemeingiiltigkeit 
davon ausgegangen werden soil, dass ein hoher Wert (1) 
far eine hohe, ein niedriger Wert (0) ftir eine niedrige 
Zuveriassigkeit stehen soil. Die erf indungsgemaiien 
Zuveriassigkeitsfunktionen beziehen sich zum einen auf 
die Zuveriassigkeit der geforderten Systemfunktionen, 
zum anderen auf die Zuveriassigkeit der 
Sicherheitsfunktionen des Systems. Nach der Bestimmung 
der entsprechenden Zuveriassigkeitsfunktionen ist es 
vorteilhaft, die konkreten Werte dieser 
Zuveriassigkeitsfunktionen ftir die gewShlte 
Systemarchitektur (oder Systemkonf iguration) zu 
berechnen, urn konkrete Aussagen aber die 
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ZuverlSssigkeit der Systemfunktionen bzw. der 
Sicherheitsfunktionen zu erhalten. 

In der Kegel sind neben der gewShlten Systemarchitektur 
5 auch andere Konf igurationen realisierbar, die zu 

denselben geforderten Systemfunktionen ftihren. Gleiches 
gilt ftir die geforderten Sicherheitsfunktionen. Es ist 
daher fUr die Wahl einer geeigneten Systemarchitektur 
von Vorteil, wenn die erfindungsgemSfi bestimmten 

10 Zuveriassigkeitsfunktionen ftir verschiedene 
Systemarchitekturen bestimmt werden. Die 
Systemarchitektur kann dabei wie folgt verandert 
werden: durch Festlegung der fur die Realisierung der 
geforderten Systemfunktionen sowie 

15 Sicherheitsfunktionen notwendigen Hardware-Komponenten 
(Art der Hardware-Komponenten, Anordnung und 
Redundanzen dieser Komponenten) ; Festlegung der fiir die 
Realisierung der geforderten Systemfunktionen sowie 
Sicherheitsfunktionen notwendigen Softwarekomponenten 

20 und schlieBlich die Zuordnung der Softwarekomponenten 
zu bestimmten Hardware komponenten. Durch Variation 
einer oder mehrerer dieser Festlegungen bzw. 
Zuordnungen iSsst sich die Systemarchitektur verandern. 

25 Hierbei ist es sinnvoll, ftir die sich ergebenden 

Systemarchitekturen die Zuverlassigkeiten (Werte der 
Zuveriassigkeitsfunktionen) zu berechnen und 
Konfigurationen mit hoher ZuverlSlssigkeit den Vorzug zu 
geben. Die berechneten Zuverlassigkeiten kcJnnen sich 

30 hierbei entweder auf die geforderten Systemfunktionen 
Oder auf die Sicherheitsfunktionen des Systems 
beziehen. Es ist jedoch von Vorteil beide 
Zuverlassigkeiten zu maximieren, um eine 
Systemarchitektur zu finden, die sowohl hinsichtlich 
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Zuveriassigkeit als auch hinsichtlich Sicherheit hohe 
Werte erzielt. 

Zur ErhOhung der Systemsicherheit ist es sinnvoll, die 
geforderten Systemfunktionen durch 

Oberwachungsfunktionen zu kontrollieren. Hierdurch 
konnen rechtzeitig Maiinahmen ergriffen werden, falls 
exne bestimmte Systemfunktion vom System nicht mehr 
geliefert werden kann. Diese Mafinahmen reichen vom 
Abgeben einer entsprechenden Information bis hin zum 
Abschalten des gesamten Systems, um etwaige Risiken zu 
minimieren. 

Die Sicherheit lasst sich weiter dadurch erh5hen, dass 
die Oberwachungsfunktionen zur Oberwachung der 
Systemfunktionen ihrerseits durch 
SystemUberwachungsfunktionen tlberwacht werden. 

Weiterhin ist es von Vorteil, wenn die 
Systemaberwachungsfunktionen wenigstens zum Teil den 
Systemabschnitt Oberwachen, der die 
Oberwachungsfunktionen zur Oberwachung der 
systemfunktionen enthait. Hierdurch lassen sich nicht 
nur die Oberwachungsfunktionen, sondern der gesamte 
Systemabschnitt (bspw. Mikrocontroller) kontrollieren 
und ein Ausfall dieses Systemabschnitt s detektieren. 

Weiterhin ist von Vorteil, wenn die 

SystemUberwachungsfunktionen auf zwei Systemabschnitte 
verteilt werden, von denen ein Systemabschnitt die 
besagten Oberwachungsfunktionen sowie die geforderten 
systemfunktionen, die von diesen Oberwachungsfunktionen 
kontrolliert werden, enthSlt. Eine solche Konf iguration 
ermeglicht nMmlich die Oberwachung der beiden 
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10 



15 



20 



25 



30 



Systemabschnitte in jedwede Richtung, insbesondere eine 
gegenseitige Oberwachung dieser Systemabschnitte. 

Das erfindungsgemSBe Verfahren lasst sich, wie im 
Folgenden naher erlautert wird, mit Vorteil dazu 
verwenden, in einem verteilten und vernetzten System 
(Steuergerat) Software-Komponenten zu Hardware- 
Komponenten (wie Mikrocontroller) optimal zuzuordnen. 
Weiterhin eignet sich das erf indungsgemaBe Verfahren 
mit Vorteil zur Festlegung der Systemarchitektur eines 
softwarebasierten elektronischen Systems, insbesondere 
eines Steuergerats, wie ein Motorsteuergerat . 

Das erfindungsgemaJie Verfahren lasst sich in der Praxis fur 
die zumeist vorkommenden komplexen elektronischen Systeme 
zweckmafiig mittels eines Computerprogramms implement ieren. 
Dieses Computerprogramm bestimmt die zugehOrigen 
Zuveriassigkeitsfunktionen bei einer gegebenen 
Systemarchitektur und berechnet hieraus die entsprechenden 
Werte fur die Zuveriassigkeit und Sicherheit des Systems. 
Bei Implementierung iiber ein Computerprogramm lasst sich 
insbesondere die Systemarchitektur effizient optimieren, 
wobei bekannte Optimierungsverf ahren (wie Monte-Carlo- 
Verfahren) zum Einsatz kommen k5nnen. Bei Verwendung eines 
Zuveriassigkeitsblockdiagramms zur Bestimmung der 
Zuveriassigkeitsfunktion kann das Computerprogramm unter 
Verwendung der eingangs dargestellten Grundregeln 
(vergleiche Tabelle oben) schnell die entsprechende 
Zuveriassigkeitsfunktion ermitteln . 

Das Computerprogramm kann auf geeigneten Datentragern, wie 
EEPROMs, Flash-Memories, aber auch DVDs, CD-ROMs, Disketten 
Oder Festplattenlaufwerken gespeichert sein. Auch das 
Herunterladen des Computerprogramms (iber interne oder 
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effentlich nutzbare Netze (Intranet bzw. Internet) ist 
mOglich. 

Figurenbeschreibung 

5 

Figur 1 zeigt eine schematische Darstellung eines Brake- 
By-Wire-Systems als Beispiel eines elektronischen 
Systems; 



10 Figur 2 zeigt das zum in Figur 1 dargestellten System 

zugeh5rige Zuverlassigkeitsblockdiagramm far die 
Funktion „Bremsen''; 

Figur 3 zeigt das Beispiel einer Abfolge von Schritten 
^5 bei der Zuveriassigkeits- und Sicherheitsanalyse 

und der Spezif ikation zuverlassiger und sicherer 
Systeme; 



20 



Figur 4 zeigt schematisch Komponenten eines Steuergerats 
als Beispiel eines verteilten und vernetzten 
Systems, das erf indungsgemSB hinsichtlich 
Sicherheit und Zuverlassigkeit uberwacht wird; 

Figur 5 zeigt verschiedene ZuverlSssigkeitsblockdiagramme 
25 fiir Funktionen des in Figur 4 dargestellten 

Systems . 

Beschreibung der bevorzugten Ausfiihrungsf ormen 



30 Die Figuren 1 und 2 wurden in der Beschreibungseinleitung 
bereits ausfiihrlich behandelt. 

Zuriachst sollen anhand der Darstellung in Figur 3 die 
Schritte einer Zuveriassigkeits- und Sicherheitsanalyse 
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dargelegt warden. Es handelt sich dabei und iterative and 
zusamxnenhangende Prozesse mit mehreren Schritten. Sie haben 
Exnfluss auf Anforderungen an die Hardware, Software und 

Auch'^^T"''"'"''"""'^'"^^^^ elektronische Syste^e, 

Auch fur dxe Sxcherheitsanalyse eines Systems werden hier 
Methoden zur Ausfallartenanalyse, wie FMEA oder FTA 
elngesetzt. Die Ausfallartenanalyse liefert eine Be^ertung 
des Risxkos ftir alia Funktionen des Systems. 
Das zuiassige Grenzrisiko wird in der Regel durch 
sicharheitstechnische Fastlegungen, wie Gesetze, Normen 
Oder Varordnungen, implicit vorgegeben. Aus de. ermitteltan 
Rxsxko far die Funktionen des Systems und dem zulassigen 
Grenzrisiko- warden dann - beispielsweise anhand von Norman 
wxa der lEC 61508 - sicherheitstechnische Anforderungen an 
das System abgeleitet, die oft grolien Einfluss auf den 
System-, den Hardware- und Software-Entwurf in der 
Elaktronikentwicklung haben. 

Far die durch die Ausfallartenanalyse bestirmnten und 
abgegrenzten, so genanntan sicherheitsrelevanten Funktionen 
des Systems mUssen besondera Schutzmaiinahmen getroffen 
werden, die beispielsweise in Hardware und Software 
realisiart werden kOnnen. 

im einzelnen zeigt Figur 3 zwei Hauptblocke 9 und 10, wobei 
der arsta Hauptblock 9 die ZuverlSssigkeits- und 
Srcherheitsanalyse, der zweite Hauptblock 10 die 
Spezifikation zuveriassiger und sicherer Systeme betrifft 
in die zuvariassigkaits- und Sicherheitsanalyse (Hauptblo;k 
9) geht zum einen die logische Systemarchitektur 11 als 
auch zum anderen die technische Systemarchitektur 12 ein 
Dxe technische Systemarchitektur 12 ist ihrerseits ein 
Ergabnis der Systemspezif ikation, wobei" eine geSnderte 
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Systemspezifikation (Systemarchitektur) eine erneute 
Zuveriassigkeits- und Sicherheitsanalyse bedingt. 

Am Anfang der ZuverlSssigkeits- und Sicherheitsanalyse 
steht zum einen die Gefahrenanalyse 13, zum anderen die 
Identifikation relevanter Komponenten und Subsysteme (mit 
14 bezeichneter Block) . Aus der Gefahrenanalyse 13 ergeben 
sich die konkreten gefahrlichen Situationen 15 und damit 
verbunden die Risiko-Ausfallarten- und Ausf allratenanalyse 
17, wie sie eingangs in der Beschreibungseinleitung 
ausfahrlich geschildert wurde. Ergebnis dieser Analyse 17 
sind die Zuveriassigkeits- und Sicherheitsanforderungen 18 
an das System. Auf der anderen Seite ergibt sich als 
Ergebnis der Identifikation 14 relevanter Komponenten und 
Subsysteme die zuverlSssigkeits- und sicherheitsrelevanten 
Komponenten und Subsysteme 16 de^ Systems. 

Aus den beiden Ergebnissen der Zuverlassigkeits- und 
Sicherheitsanalyse, nSmlich die zuverlassigkeits- und 
sicherheitsrelevanten Komponenten und Subsysteme 16 sowie 
die zuverlassigkeits- und Sicherheitsanforderungen 18 an 
das System, wird eine notwendige und mSgliche 
Systemspezifikation (Hauptblock 10) abgeleitet. Die 
relevanten Komponenten und Subsysteme beeinflussen die 
Definition 19.des Verif ikations- und Validationsprozesses 
sowie die Definition 20 der Anf orderungen an technische 
Komponenten und Subsysteme. Die Zuverlassigkeits- und 
Sicherheitsanforderungen 18 an das System beeinflussen die 
Definition des Sof twareentwicklungsprozesses (Block 21) . 

Konkrete Ergebnisse sind hier der Verif ikations- und 
Validationsprozess 22, die Zuverlassigkeits- und 
Sicherheitsanforderungen 23 an die Hardware, die 
Zuverlassigkeits- und Sicherheitsanforderungen 24 an die 
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software sowie der eigentliche Software-Entwicklungsprozess 
2 5 • 

Diese vier Ergebnisse ftihren zum Gesamtergebnis der 
technischen Systemarchitektur 12. Diese technische 
Systemarchitektur kann unter Umstanden korrigiert werden 
und die genannten Schritte daraufhin wiederholt werden, um 
zu uberprtifen, ob die geanderte Systemarchitektur zu einem 
System hOherer Zuverlassigkeit und Sicherheit fiihrt. 

Der Nachweis der Sicherheit und Zuverlassigkeit dieser 
Oberwachungskonzepte ist Voraussetzung far die Zulassung 
von Fahrzeugen zum StraUenverkehr . im folgenden wird am 
Beispiel des Oberwachungskonzeptes ftir ein E-Gas-System das 
Verfahren zur Beurteilung der Zuverlassigkeit und 
Sicherheit des Oberwachungskonzeptes unter Einsatz von 
Zuverlassigkeitsblockdiagrammen dargestellt . 

Als msgliche Gefahr fiir ein E-Gas-System wird ungewolltes 
Gasgeben und ein daraus folgender Unfall angenommen. Fur 
das Motorsteuergerat bedeutet dies, dass alle diejenigen 
Steuerungs- und Regelungsfunktionen f„ sicherheitsrelevant 
sind, die zu einer unbeabsichtigten Erh6hung des 
Motordrehmoments ftihren kSnnen. Ftir diese Funktionen ist 
deshalb ein Oberwachungskonzept notwendig. 

In diesem Beispiel soil das etwas vereinfachte 
Oberwachungskonzept, wie es seit Jahren in 
Motorsteuergeraten eingesetzt wird, bezUglich der 
Sicherheit und Zuverlassigkeit anhand des erf indungsgemaiien 
Verfahrens untersucht werden. Im Rahmen des Arbeitskreises 
„E-Gas- des Verbandes der Automobilindustrie (VDA) wird 
dieses von der Robert Bosch GmbH entwickelte Basiskonzept 
derzeit zu einem standardisierten Oberwachungskonzept far 
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Motorsteuerungen von Otto- und Dieselmotoren 
weiterentwickelt . 



In Figur 4 ist das Oberwachungskonzept fOr 

sicherheitsrelevante Steuerungs- und Regelungsf unktionen f„ 
dargestellt. 

In Figur 4 ist als softwarebasiertes elektronisches System 
ein Steuergerat 30 dargestellt. Ein erster Mikrocontroller 
31 dient als Funktionsrechner, wahrend ein zweiter 
Mikrocontroller 32 als Oberwachungsrechner eingesetzt wird. 
Signale gelangen in die Eingangsstufe 33 des SteuergerSts 
30 und werden von dort dem A/D-Wandler 34 im 
Mikrocontroller 31 zugefUhrt. Das digitalisierte Signal 
lost die eigentlichen Steuerungs- und Regelungsf unktionen 
fn (Block 41) aus. Parallel werden die Signale dem Block 42 
zugefUhrt, der die Funktionen zur Oberwachung der 
Steuerungs- und Regelungsf unktionen enthSlt. Zur 
Oberwachung der Steuerungs- und Regelungsfunktionen ist der 
Block 41 mit dem Block 42 verbunden. Die genannten 
Oberwachungsfunktionen fan werden ihrerseits von Funktionen 
zur Oberwachung der Mikrocontroller, d. h. den so genannten 
Systemtiberwachungsf unktionen, tiberprtift. Hierzu ist der 
Block 42 mit dem Block 43 verbunden. Die Blocks 41, 42 und 
43 sind Bestandteil der Software 45 des Mikrocontrollers 
31. Die Bl5cke 42 und 43 haben reine 
Oberwachungsf unktionen. 

Weiterhin in Figur 4 dargestellt ist der als 
Oberwachungsrechner dienende Mikrocontroller 32, zu dessen 
Software 46 die Funktionen zur Oberwachung der 
Mikrocontroller (Block 44) gehdren. Hieraus ist 
ersichtlich, dass diese Funktionen zur Oberwachung der 
Mikrocontroller (SystemUberwachungsfunktionen) auf die 
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beiden Mikrocontroller 31 und 32 verteilt sind. Hierauf 
wird spater eingegangen. Die Bl6cke 42, 43 und 44 
reprasentieren die Oberwachungsfunktionen 29. 

5 Die vom SteuergerSt ausgeftihrten Steuerungs- und 

Regelungsfunktionen fn (Block 41) werden in Form eines 
Ausgangssignales an einen D/A-Wandler 35 gelegt, dessen 
Ausgang an der Endstufe 40 liegt. Die AusgSnge 36, 37 und 
38 der die Oberwachung wahrnehmenden BlOcke 42, 43 bzw. 44 

10 werden einem Addierglied 39 zugeftihrt, so dass das Erkennen 
eines Fehlers durch einen der drei Bl«5cke 42, 43 oder 44 zu 
einem entsprechenden Ausgangssignal des Addiergliedes 39 
fiihrt. Letzteres ist mit der Endstufe 40 verbunden, wodurch 
je nach Art des Fehlers auf die Endstufe definiert Einfluss 

15 genommen werden kann. 

Im Folgenden soil auf die Funktion des in Figur 4 
dargestellten (Jberwachungskonzepts naher eingegangen 
werden . 



20 



25 



Die sicherheitsrelevanten Steuerungs- und 
Regelungsfunktionen fn werden durch die 
Oberwachungsfunktionen fon standig tiberwacht. Die 
Oberwachungsfunktionen fon verwenden die gleichen 
EingangsgrSfien wie die Steuerungs- und Regelungsfunktionen 
fn, arbeiten aber mit unterschiedlichen Daten und mit 
unterschiedlichen Algorithmen. 



30 



Die Funktionen zur Oberwachung der Mikrocontroller 
(=Systemaberwachungsfunktionen) prafen neben RAM-, ROM- und 
Mikroprozessorfunktionen beispielsweise auch, ob die 
Steuerungs- und Regelungsfunktionen f„ und die 
Oberwachungsfunktionen fo„ uberhaupt ausgeftihrt werden. 
Dies macht in diesem Beispiel den Einsatz eines zweiten 
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10 



Mikrocontrollers 32 im MotorsteuergerSt 30, eines so 
genannten Oberwachungsrechners, notwendig. Die Funktionen 
zur Oberwachung der Mikrocontroller 31, 32 warden auf den 
Funktionsrechner und den Oberwachungsrechner verteilt. 
Beide tiberwachen sich bevorzugt in einem Frage-Antwort- 
Spiel gegenseitig. 

Als sicherer Zustand ist in diesem Ausf uhrungsbeispiel die 
Stromabschaltung far die elektromechanische Drosselklappe 
festgelegt. Die Drosselklappe ist so konstruiert, dass sie 
nach einer Stromabschaltung selbsttatig die 
Leerlauf position einnimmt. Der Obergang in den sicheren 
Zustand kann deshalb dadurch eingeleitet werden, dass eine 
Abschaltung der Endstufen 40 des SteuergerSts, die die 
15 Drosselklappe ansteuern, erfolgt. Der Motor kann so im 
Notlauf weiterbetrieben werden. 

Sowohl die Oberwachungsfunktionen fon, als auch die 
Funktionen zur Oberwachung der Mikrocontroller auf dem 

20 Funktions- und auf dem Oberwachungsrechner kOnnen also die 
Drosselklappenendstufen des Steuerger^ts 30 abschalten, 
Im Falle eines erkannten Fehlers wird neben dieser 
Sicherheitsreaktion auch ein Eintrag im Fehlerspeicher 
vorgenommen. AuJJerdem wird meist auch eine Information an 

25 den Fahrer etwa Ober eine Anzeige im Kombiinstrument 
ausgegeben. 

Soli die Zuveriassigkeit dieses Oberwachungskonzepts 
beurteilt werden, so sind zunachst drei Arten von 
30 Funktionen zu unterscheiden: 

o die Steuerungs- und Regelungs funktionen f„ 
o die Oberwachungsfunktionen fon 
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10 



15 



20 



25 



30 



o die Funktionen zur Oberwachung der Mikrocontroller 

(-Systemtiberwachungsfunktionen) 
Die Zuveriassigkeitsblockdiagramme 45, 46, 47 far diese 
verschiedenen Funktionen lassen sich dann recht einfach 
bestiminen und sind in Figur 5 dargestellt. 

Um die Systemzuveriassigkeit zu bestimmen, wird man alle 
drei Arten von Funktionen gleichzeitig fordern. Dann ergibt 
sxch die Systemzuveriassigkeit durch eine Reihenschaltung 
dxeser Blockdiagramme . Zusatzlich massen auch die 
Komponenten K, und Ke (Verbindung der B15cke 43 und 44 in 
Fxg. 4), die in den Blockdiagrammen der einzelnen 
Funktionen nicht vorkommen, in Reihe geschaltet warden. 

Die Systemzuverlassigkeit R3 zuverx.ssi^.eit ergibt sich durch 
Multiplikation der ZuverlSssigkeit der drei Funktionen R, . 
X - A, B, c mit der Zuveriassigkeit der Komponenten R, und ' 
Kb R, und ist wegen Rx < 1 in jedem Fall geringer als die 
Deweilige Zuveriassigkeit der Funktionen R^. Bei der 
Berechnung der Systemzuverlassigkeit mussen die Regeln fUr 
das Rechnen mit mehrfach auftretenden Elementen im 
Zuverlassigkeitsblockdiagrammen beachtet werden (vgl 
Alessandro Birolini: Zuveriassigkeit von GerSten und 
Systemen, Anmerkungen oben) . 

Rs zuveriassigkeit = Ra Rb Rc Rd Re 

Dagegen ist ftir die Sicherheit lediglich das zuverlSssige 
Erkennen eines Ausfalls und der zuverlSssige Obergang in 
den sicheren Zustand notwendig. Die Zuveriassigkeit R3 
Sicherheit dieser Sicherheitsreaktion wird durch die 
Zuveriassigkeit der Oberwachungsf unktionen fo„ oder der 
Funktionen zur Oberwachung der Mikrocontroller vorgegeben 
und ist deshalb hoher als die Zuveriassigkeit der 
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Funktionen Rx- Zudem geht die Zuveriassigkeit der 
• Komponenten Kt Rd und Kg Re in die Berechnung von Rs 
sicherheit nicht ein. 

5 Die Zuveriassigkeitsfunktion ftlr die Zuveriassigkeit der 
Sicherheitsfunktion (-reaktion) ist wie folgt: 



10 



15 



20 



S Sicherheit = 1 - (1 - Rb ) (1 - Rc) 



Wie dieses Beispiel zeigt, kSnnen MalSnahmen zur Erhohung 
der Sicherheit die Zuveriassigkeit des Systems verringern. 
Aufierdem ist ersichtlich, dass Mafinahmen zur ErhShung der 
Zuveriassigkeit zu einer Reduzierung der Sicherheit eines 
Systems fUhren kOnnen. 



Obwohl beim erf indungsgemafien Verfahren im Grunde nur 
Hardware-Komponenten und -Verbindungen betrachtet werden, 
haben die Zuveriassigkeits- und Sicherheitsanalysen groBen 
Einfluss auf die Software-Entwicklung. Wie am Beispiel der 
Bewertung des Oberwachungskonzeptes gezeigt, beeinflussen 
sie etwa die Zuordnung der Sof tware-Funktionen zu den 
Mikrocontrollern in einem verteilten und vernetzten System 
Oder die notwendigen QualitatssicherungsmaBnahmen in der 
Software-Entwicklung. Dies ist gegenOber dem Stand der 
25 Technik ein enormer Fortschritt und fUhrt zu groJien 
Vorteilen bei der Systementwicklung. 

Das erfindungsgemaiie Verfahren ermSglicht die folgende 
Vorgehensweise zur OberprUfung der Sicherheit und 
30 Zuveriassigkeit softwarebasierter elektronischer Systeme 
(vgl. Figuren 4 und 5) : 
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Schritt 1: Festlegung des Hardware-Net zwerks des 

elektronischen Systems, d. h. insbesondere Spezif ikation 
der Mikrocontroller 31, 32 und ihrer Vernetzung; 
Schritt 2: Festlegung der Software-Komponenten 41 - 44, 

5 die ftir die Realisierung der Funktionen des elektronischen 
Systems erforderlich sind und Spezif ikation der 
Kommunikation zwischen den Software-Komponenten 41 - 44; 
Schritt 3: Zuordnung der Software-Komponenten 41-44 

zu den Mikrocontrollern 31, 32 des Hardware-Net zwerks; 
10 Schritt 4 : Auf stellen der 

Zuveriassigkeitsblockdiagramme 45 - 47 ftir die geforderten 
Funktionen des elektronischen Systems 30 ausgehend von den 
Hardware-Komponenten und Hardware-Verbindungen Ki, 

15 Schritt 5: Nachweis der Sicherheit und Zuverlassigkeit 

durch Berechnung der Zuverlassigkeit ftir die 
Sicherheitsfunktionen und der Zuverlassigkeit far die 
gesamten geforderten Funktionen des elektronischen Systems 
(30) ; 

20 Schritt 6: ggf . Wiederholung der Schritte 1 bis 5 und 

Korrektur der Systemarchitektur, d. h. 

des Software- und Hardware-Netzwerks, sowie der Zuordnung 
der Software-Komponenten zu Hardware-Komponenten. 
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Ansprtiche 



1. Verfahren zur Oberprafung der Sicherheit und 
Zuverlassigkeit sof twarebasierter elektronischer Systeme 
unter Verwendung einer ZuverlMssigkeitsfunktion zur 
Oberprtlfung der geforderten Funktionen des Systems (30) auf 
der Grundlage der hierfQr notwendigen Hardwarekoitiponenten 
des Systems (30) , 



dadurch gekennzeichnet. 



d a s s 



eine Zuverlassigkeitsfunktion zur Berechnung der 
Zuverlassigkeit mindestens einer der geforderten Funktionen 
des Systems (30) und eine weitere Zuverlassigkeitsfunktion 
zur Berechnung der Zuverlassigkeit mindestens einer der 
Sicherheitsfunktionen des Systems (30) bestimmt werden, 
wobei zur Bestimmung dieser Zuverlassigkeitsfunktionen 
Software-Komponenten (41, 42, 43, 44) des Systems anhand 
der Hardware-Komponenten, auf die diese Software- 
Komponenten (41, 42, 43, 44) verteilt sind, 
mitberUcksichtigt werden. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, 
dass eine Zuverlassigkeitsfunktion fUr alle geforderten 
Funktionen des Systems (30) bestimmt wird. 



wo 2005/003972 



- 27 - 



PCT/DE2004/001317 



3. Verfahren nach Anspruch 1 oder 2 , dadurch 
gekennzeichnet, dass eine ZuverlSssigkeitsf unktion fur alle 
Sicherheitsfunktionen des Systems (30) bestimmt wird. 

5 4. Verfahren nach einem der Ansprtiche 1 bis 3, dadurch 
gekennzeichnet, dass die Werte der beiden 
Zuveriassigkeitsfunktionen fiir eine bestimmte 
Systemarchitektur berechnet werden. 

10 5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, 
dass die Systemarchitektur durch eine oder mehrere der 
folgenden Bestandteile verandert wird: Festlegung der far 
die Realisierung der geforderten Systemfunktionen und 
Sicherheitsfunktionen notwendigen Hardware-Komponenten; 

15 Festlegung der fur die Realisierung der geforderten 

Systemfunktionen und Sicherheitsfunktionen notwendigen 
Software-Komponenten; und die Zuordnung der Software- 
Komponenten zu Hardware-Komponenten. 

20 6. Verfahren nach Anspruch 4 oder 5, dadurch ■ 

gekennzeichnet, dass die Systemarchitektur anhand einer 
Maximierung der berechneten Zuverlassigkeiten fur die 
geforderten Systemfunktionen bei unterschiedlichen 
Systemarchitekturen optimiert wird. 



25 



7. Verfahren nach Anspruch 4, 5 oder 6, dadurch 
gekennzeichnet, dass die Systemarchitektur anhand einer 
Maximierung der berechneten Zuverlassigkeiten far die 
Sicherheitsfunktionen des Systems bei verschiedenen 

30 Systemarchitekturen optimiert wird. 

8. Verfahren nach einem der Ansprache 1 bis 7, dadurch 
gekennzeichnet, dass eine Zuverlassigkeitsf unktion mittels 
ernes ZuverlSssigkeitsblockdiagramms bestimmt wird 
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9. Verfahren nach einem der Ansprtiche 1 bis 8, dadurch 
gekennzaichnet, dass die geforderten Syste^nfunktionen durch 
Oberwachungsfunktionen zur Oberwachung dieser 
Systemfunktionen tiberwacht werden, wobei die 
Oberwachungsfunktionen ihrerseits durch 
SystemUberwachungsfunktionen tiberwacht werden. 

10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, 
dass die Systemtlberwachungsfunktionen wenigstens zum Teil 
den Systemabschnitt (31) uberwachen, der die 

Oberwachungsfunktionen zur Oberwachung der Systexnfunktionen 
entnalt . 



11. verfahren nach Anspruch 10, dadurch gekennzeichnet, 
dass die Systemtlberwachungsfunktionen auf zwei 
Systexnabschnitte (31, 32) verteilt werden, von denen ein 
systemabschnitt (31) die geforderten Systemfunktionen sowie 
deren Oberwachungsfunktionen enthait. 

12. verfahren nach Anspruch 11, dadurch gekennzeichnet, 
dass beide Systemabschnitte (31, 32) sich gegenseitig aber 
die Systemiiberwachungsfunktionen iiberwachen. 

13. verfahren nach einem der AnsprQche 1 bis 12, dadurch 
gekennzeichnet, dass zur Oberprafung der Sicherheit und 
Zuverlassigkeit des Systems (30) folgende Schritte 
ausgefahrt werden: 

Festlegung von Hardware-Komponenten des Systems (30) 
und deren Vernetzung, insbesondere Spezif ikation der 
Mikrocontroller (31, 32) und ihrer Vernetzung; 

Festlegung von Sof tware-Komponenten (41, 42 43 44) 
des systems (30), die fur die Realisierung der " ' 
Systemfunktionen und der Sicherheitsf unktionen des Systems 
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(30) erforderlich sind und Spezif ikation der Komraunikation 
zwischen den Software-Komponenten (41, 42, 43, 44); 

Zuordnung der Software-Komponenten (41, 42, 43, 44) zu 
Hardware-Koiuponenten, insbesondere zu den Mikrocontrollern 
(31, 32) des Systems (30) ; 

Aufstellen der Zuveriassigkeitsblockdiagramme (45, 46, 
47) ftir die geforderten Funktionen des Systems (30) 
einschliefilich der Sicherheitsfunktionen ausgehend von den 
Hardware-Komponenten und Hardware-Verbindungen; 

Berechnung der ZuverlSssigkeit fiir die 
Sicherheitsfunktionen und der Zuverlassigkeit ftir die 
gesamten geforderten Funktionen des Systems (30) zum 
Nachweis der Sicherheit und Zuverlassigkeit des Systems 



14. Verfahren nach Anspruch 13, dadurch gekennzeichnet 
dass als weiterer Schritt die Systemarchitektur, also das 
Software- und Hardware-Netzwerk sowie die Zuordnung der 
Software-Komponenten zu Hardware-Komponenten, korrigiert 
wird und die Schritte gemSB Anspruch 13 wiederholt werden. 

15. Verwendung eines Verfahrens nach einem der AnsprQche 1 
bis 14 zur Zuordnung der Software-Komponenten (41, 42, 43 
44) zu Hardware-Komponenten, wie Mikrocontroller (31, '32)! 
in einem verteilten und vernetzten System (30). 

16. Verwendung eines Verfahrens nach einem der Ansprtlche 1 
bxs 14 zur Festlegung der Systemarchitektur eines 
Steuergerats (30), wie Motorsteuergerat . 

17. Computerprogramm mit Programmcode-Mitteln, urn alle 
Schritte eines Verfahrens gema/i einem der Ansprtiche 1 bis 
14 durchzufahren, wenn das Computerprogramm auf einem 
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Computer oder einer entsprechenden Rechnereinheit 
ausgeftihrt wird. 

18. Computerprogrammprodukt mit Programmcode-Mitteln, die 
auf einem computerlesbaren DatentrSger gespeichert sind, um 
alls Schritte eines Verfahrens nach einem der Ansprache 1 
bis 14 durchzuftihren, wenn das Computerprogrammprodukt auf 
einem Computer oder auf einer entsprechenden Rechnereinheit 
ausgeftihrt wird. 
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Fig. 2 



wo 2005/003972 



PCT/DE2004/001317 



2/4 




Fig„3 




Fig. 4 
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Fig. 5 



